Stefano Zacchiroli opened DebConf 14 with an insightful talk titled Debian in the Dark Ages of Free Software (slides available, video available soon). He makes the point (quoting slide 16) that the Free Software community is winning a war that is becoming increasingly pointless: yes, users have 100% Free Software thin client at their fingertips [or are really a few steps from there]. But all their relevant computations happen elsewhere, on remote systems they do not control, in the Cloud. That give-up on control of computing is a huge and important problem, and probably the largest challenge for everybody caring about freedom, free speech, or privacy today. Stefano rightfully points out that we must do something about it. The big question is: how can we, as a community, address it? Towards a Free Service Definition? I believe that we all feel a bit lost with this issue because we are trying to attack it with our current tools & weapons. However, they are largely irrelevant here: the Free Software Definition is about software, and software is even to be understood strictly in it, as software programs. Applying it to services, or to computing in general, doesn t lead anywhere. In order to increase the general awareness about this issue, we should define more precisely what levels of control can be provided, to understand what services are not providing to users, and to make an informed decision about waiving a particular level of control when choosing to use a particular service. Benjamin Mako Hill pointed out yesterday during the post-talk chat that services are not black or white: there aren t impure and pure services. Instead, there s a graduation of possible levels of control for the computing we do. The Free Software Definition lists four freedoms how many freedoms, or types of control, should there be in a Free Service Definition, or a Controlled-Computing Definition? Again, this is not only about software: the platform on which a particular piece of software is executed has a huge impact on the available level of control: running your own instance of WordPress, or using an instance on wordpress.com, provides very different control (even if as Asheesh Laroia pointed out yesterday, WordPress does a pretty good job at providing export and import features to limit data lock-in). The creation of such a definition is an iterative process. I actually just realized today that (according to Wikipedia) the very first occurrence of an attempt at a Free Software Definition was published in 1986 (GNU s bulletin Vol 1 No.1, page 8) I thought it happened a couple of years earlier. Are there existing attempts at defining such freedoms or levels of controls, and at benchmarking such criteria against existing services? Such criteria would not only include control over software modifications and (re)distribution, but also likely include mentions of interoperability and open standards, both to enable the user to move to a compatible service, and to avoid forcing the user to use a particular implementation of a service. A better understanding of network effects is also needed: how much and what type of service lock-in is acceptable on social networks in exchange of functionality? I think that we should inspire from what was achieved during the last 30 years on Free Software. The tools that were produced are probably irrelevant to address this issue, but there s a lot to learn from the way they were designed. I really look forward to the day when we will have:

• a Free Software Definition equivalent for services
• Debian Free Software Guidelines-like tests/checklist to evaluate services
• an equivalent of The Cathedral and the Bazaar, explaining how one can build successful business models on top of open services

Exciting times!

Debsources: Live and Historical Views on Macro-Level Software Evolution The paper entitled Debsources: Live and Historical Views on Macro-Level Software Evolution, which I've co-authored with Matthieu Caneill, has been accepted at ESEM 2014: the 8th international symposium on Emprical Software Engineering and Measurement. In the paper we have described Debsources as a software platform for monitoring the evolution of Free Software through the lenses of Debian, and used the main Debsources instance (http://sources.debian.net) to replicate and extend a former study on macro-level software evolution. Now we "just" have to integrate all the nice charts and data we have extracted for the paper into Debsources' stats page... /o\

moar, and moar, and moar debsources stats A while ago I've announced the availability of several stats about Debian source code on http://sources.debian.net. Since then the statistical basis of those stats has increased a lot, and now includes all Debian historical releases, from hamm (July 1998) onward. This allows to appreciate macro-level evolution trends in Free Software, over a period of more than 15 years, through the eyes of a distro that sits at the nice intersection of the eldest, largest, and most reputed distros. To get there I've added support for sticky suites to the plumbing layer of debsources, and then injected historical releases from http://archive.debian.org. The injection process took about a week (without any sort of parallelism, pretty slow disks, and computing sha256 checksums, ctags, and sloccount on all source files) and has been an "interesting" experience. When you go back decades in technology time, bit rot is just around the corner, and I've found my share while injecting archive.d.o into sources.d.n. In both cases the respective maintainers (Guillem and Ganneff, kudos) have been positive about and helpful in improving the situation, despite the low impact of the bugs I've found on the average user. That's quite important for the long-term preservation of digital information in general, and for the perennity of access to Free Software in the specific case of Debian. While we are it, I'm now maintaining a list of bugs affecting sources.d.n but belonging to other packages, in case you fancy helping out but are not a Python hacker. Interestingly enough, quite a bit of those bugs are related to the fact that tools debsources uses (e.g. ctags, sloccount) are also starting to show their age. You might wander why buzz, rex, and bo are still missing from sources.d.n. That's in fact for similar reasons. Before hamm Debian didn't have complete archive coverage in terms of Sources indexes and .dsc files. Given that debsources rely on both to extract source packages, it first needs to grow an additional abstraction layer that can cope with their absence. It's SMOP, and planned. And now let's have fun with ctags bombs. Yours truly,
Stefano Indiana Zacchiroli
(credits: KiBi, #debian-ftp)

Debian: watch your stats! Over the past few weeks, myself and Matthieu Caneill have worked quite a bit on Debsources. As we have now deployed most of the new features on http://sources.debian.net, it's time for another "What's new with Debsources?" blog post. Here is what's new:

• Debsources now knows about Debian suites, i.e. which package is in which "release" (stable, testing, unstable, ...). This knowledge is already useful for some of the other features below and will be used more in the future.
• since last summer Debsources has been running sloccount on all unpacked source packages, together with ctags and du, but the resulting information wasn't exposed on the Web. This is now fixed. Each package now has an infobox (example) which shows: disk usage, archive area, suites, and sloccount with per-language breakdown. The new infobox also subsumes the old puny list of package links. You can easily embed the infobox in other webapps if you need to (example). Check the URL scheme doc for more info.
• Debsources now gathers and plot accurate Debian sources statistics, both overall and per-suite, in both snapshot and historical trends flavors. (Yeah, I know, the charts are not particularly good looking ATM, but that's easy to change without impacting the rest. So if you're a matplotlib artist and willing to help, please step forward!)
• many changes have been going on also at the plumbing layer to make the service less resource hungry and more maintainable, in view of a migration to the official Debian infrastructure --- which I've in the meantime started discussing with DSA. Some highlights:
  • Debsources now has a rather comprehensive test suite, built using Nose. Most notably, we do test full update runs down to source unpacking (of a small subset of a Debian mirror), DB injection, and plugin execution --- which is quite neat.
  • the updater is now much faster (about 2x) and might require, in pathological cases, 10x less memory than before. Memory usage now caps at around 300MB, even when injecting ctags for large packages such as linux, chromium, and libreoffice.
  • the DB schema went through several refactoring cycles, and now uses a separate file table to index all known source file paths. In the past path information were duplicated across the checksums and ctags tables, not only wasting DB space, but also making the presence of file information conditional on the enablement of at least one of the two corresponding plugins. This is now fixed --- and migrating the full DB has been quite "fun". Unfortunately, we've also added quite a few large-ish indexes, resulting in no significant overall changes in DB size (currently at ~50GB), but at least in much faster queries The next step on this front will be the addition of path-based searches, using the excellent Postgres trigram indexes.

Want more? Sure, we'll be happy to! But it'll happen faster if you help. Speaking of which: we've got Debsources into the new contributors game (see announcement) and we're looking forward to mentor new contributors.

This is a repost from Stefano Zacchiroli's post how-can-i-help by Lucas Nussbaum is one of the best things that happened in the area of attracting contributions to Debian in quite a while. It can be used both as a standalone tool to list opportunities for contributing to Debian which are related to your installed packages, and as an APT hook (which is also the default configuration) that at each upgrade will inform you of new contribution opportunities. how-can-i-help is great for newbies who are looking for ways to give back to Debian which are a good match for their skills: among other things, how-can-i-help shows bugs tagged "gift" related to packages you use. how-can-i-help is also great for experienced developers, as it allows them to find out, in a timely manner, that packages they use are in dire need of help: RC bugs, pending removals, adoptions needed, requests for sponsor, etc. (As highly unscientific evidence: I've noticed a rather quick turnover of RFA/O/ITA bugs on packages installed on my machine. I suspect how-can-i-help is somehow responsible for that, due to the fact that it increases awareness of ongoing package issues directly with the people using them.) So, if you haven't yet, please apt-get install how-can-i-help RIGHT NOW. I daresay that we should aim at installing how-can-i-help by default on all Debian machines, but that might be an ambitious initial goal. In the meantime I'll settle for making how-can-i-help's popcon count skyrocket. As of today, it looks like this: which is definitely too low for my taste. Please spread the word about how-can-i-help. And let's see what we can collectively do to that graph. how-can-i-help is just a tiny teeny helper, but I'm convinced it can do wonders in liberating dormant contributions to the Debian Project.

skyrocketing how-can-i-help popcon count how-can-i-help by Lucas Nussbaum is one of the best things that happened in the area of attracting contributions to Debian in quite a while. It can be used both as a standalone tool to list opportunities for contributing to Debian which are related to your installed packages, and as an APT hook (which is also the default configuration) that at each upgrade will inform you of new contribution opportunities. how-can-i-help is great for newbies who are looking for ways to give back to Debian which are a good match for their skills: among other things, how-can-i-help shows bugs tagged "gift" related to packages you use. how-can-i-help is also great for experienced developers, as it allows them to find out, in a timely manner, that packages they use are in dire need of help: RC bugs, pending removals, adoptions needed, requests for sponsor, etc. (As highly unscientific evidence: I've noticed a rather quick turnover of RFA/O/ITA bugs on packages installed on my machine. I suspect how-can-i-help is somehow responsible for that, due to the fact that it increases awareness of ongoing package issues directly with the people using them.) So, if you haven't yet, please apt-get install how-can-i-help RIGHT NOW. I daresay that we should aim at installing how-can-i-help by default on all Debian machines, but that might be an ambitious initial goal. In the meantime I'll settle for making how-can-i-help's popcon count skyrocket. As of today, it looks like this: which is definitely too low for my taste. Please spread the word about how-can-i-help. And let's see what we can collectively do to that graph. how-can-i-help is just a tiny teeny helper, but I'm convinced it can do wonders in liberating dormant contributions to the Debian Project.

Over the next few weeks I'll be on the road, attending a few Free Software events and giving talks. In particular:

• during the upcoming week-end (18-19 January 2014) there will be a mini-DebConf in Paris. I'll be there to give a talk about Debsources (see schedule), participate in the Debian France plenary meeting, and meet Debian friends from all over Europe.
• two weeks later (1-2 February 2014) I'll be at FOSDEM 2014 to give a retrospective talk about legal issues that Debian has faced over the past few years, participate in a panel about Free Software governance, and meet Free Software friends from all over the world!
• the day after FOSDEM end (3 February 2014) I'll be in Antwerp for the opening keynote of the SQM workshop to discuss some of my research work at IRILL and current challenges in the field

See you "there"?

org-mutt with org-mode >= 8 Thanks to Don I just remembered that I haven't yet announced org-mutt support for org-mode >= 8. Let's catch up! Since a few weeks I've been aware of the fact that my mutt/org-mode glue, AKA org-mutt, was no longer working with org-mode >= 8, due to the ditching of org-remember in favor of org-capture. Allegedly, org-capture should have been backward compatible, but it clearly is not. Before I had time to fix it myself, Mako came to my rescue and submitted a patch (now accepted) that does the needed porting. Free Software is truly amazing, isn't it? I've just updated the canonical org-mutt blog post, so that the documentation in there is up to date again. If you're using org-mutt, I suggest to refer to the Git repository as the canonical location for future updates, if any. Thanks Don, thanks Mako!

I use org mode extensively, and had added Zack's workflow for integrating mutt with org mode to my ~/.emacs some time ago. However, I've been annoyed that refiling closes the org-capture frame before refiling finishes. The following trivial modification to Zack's code (which I previously modified to work with org-mode >= 0.8) waits to close the frame until you've finished refiling.

 (require 'org-protocol)
 (add-hook 'org-capture-mode-hook 'delete-other-windows)
 (setq my-org-protocol-flag nil)
 (defadvice org-capture-finalize (after delete-frame-at-end activate)
   "Delete frame at remember finalization"
   (progn (if my-org-protocol-flag (delete-frame))
          (setq my-org-protocol-flag nil)))
 (defadvice org-capture-refile (around delete-frame-after-refile activate)
   "Delete frame at remember refile"
   (if my-org-protocol-flag
       (progn
         (setq my-org-protocol-flag nil)
         ad-do-it
         (delete-frame))
     ad-do-it)
   )
 (defadvice org-capture-kill (after delete-frame-at-end activate)
   "Delete frame at remember abort"
   (progn (if my-org-protocol-flag (delete-frame))
          (setq my-org-protocol-flag nil)))
 (defadvice org-protocol-capture (before set-org-protocol-flag activate)
   (setq my-org-protocol-flag t))

Now, the frame automatically disappears after you refile it, keeping my refile.org clean.

and thanks for all the sigs Bandwagoning just a bit, and only a few days past the 3-year anniversary of my 4096R GPG key, I've finally got my acts together and revoked my old 1024D GPG key. If you haven't yet switched to a GPG key stronger than 1024D, you definitely should.
Think of the kittens.

all your ctag (and checksum) are belong to us A few months after the initial announcement, here are some news about the sources.d.n service. I've been late in blogging this, but most of it has been implemented by myself and Matthieu Caneill during DebConf13, which has been a great DebConf, totally exceeding my expectations (and they were already fairly high!). First, you might have noticed some user-visible changes:

• there is now an advanced search page, which complements the already existing regex code search with the possibility of searching source files by their sha256, or the ctags defined therein
• on the same topic, when browsing through a package and using regex search, you'll now search by default within that package, allowing to focus your searches more easily than before. (You can easily override this by editing the search box and removing the package: predicate.)
• for the data geeks (or the wannabe host), there are now disk usage stats (note that they don't include the database size, though, see below for that)
• the website also got a significant facelift, as part of which we have moved the detailed explanations of what the service is about out of your way. You now immediately get to the various browsing options.

On the other hand, under the hood:

• to implement ctags and sha256 searches we needed a serious DBMS, so we switched from SQLite to PostgreSQL. Again, for the data geek: storing ctags/sha256 for all of sources.d.n content with decent indexes takes about 37 GB, for about 160 million rows in the ctags table and 20 million rows in the checksums one. (Currently filenames are duplicated between the two tables so, probably, the DB disk size might be reduced some.)
• together with the switch to a serious DBMS, the update logics has been completely rewritten in Python (from Bash...), and should now be entirely transactional.
• ... and given it was going to be Python anyhow, better to enjoy what it has to offer, no? So there is now a plugin mechanism that makes it easier to add extra data extractors, triggering them at each package update. Currently there are plugins for sha256sum, ctags, and sloccount (even though the latter is not yet exposed via the web interface). An added benefit of this is that if you want to deploy debsources elsewhere, you can easily disable the most time consuming extractors: running ctags and sha256sum on the fabulous 3 chromium/libreoffice/linux is not for the faint of disks...
• we now receive push updates from the Debian mirror network, so that you'll get updates on sources.d.n as soon as a package hits Debian mirrors (+ processing time, which is about 15-20 minutes on the average update run). Many thanks to Simon Paillard and Adam Lackorzynski for their help in setting this up.
• thanks to a suggestion by kugel we have adopted Geany's conventions for filetype detection, and we now take into account both file extensions and shebang lines (when available)

As you usual, your bug reports (and patches!) are more than welcome, just check BUGS before reporting to avoid duplicates.
That's all!

Small update as someone was complaining about the lack of pictures from DebCamp on planet. Not to worry, everything is going fine, and some of the most important stuff is ready You can see a few pictures from the gallery. The view from the venue is quite outstanding (it was better when there was some sun on Tuesday, but my camera battery was out ). On my TODO-list:

• A lot of mentors.d.n related stuff : prototyping things to make our codebase more bearable by actually using other people s work, e.g. debianqueued, firehose, , and building upon Lucas s idea from his new contributor survey (see the quite vague idea at the bottom)
• FedMsg stuff (will probably pick up when Simon arrives)
• Some 3D-printing packaging stuff (actually getting software in NEW, I got started on Printrun, and maybe Slic3r)

See you there!

This is a verbatim repost from Stefano Zacchiroli's post TL;DR: go to http://sources.debian.net and enjoy.

---

Debsources is a new toy I've been working on at IRILL together with Matthieu Caneill. In essence, debsources is a simple web application that allows to publish an unpacked Debian source mirror on the Web. You can deploy Debsources where you please, but there is a main instance at http://sources.debian.net (sources.d.n for short) that you will probably find interesting. sources.d.n follows closely the Debian archive in two ways:

1. it is updated 4 times a day to reflect the content of the Debian archive
2. it contains sources coming from official Debian suites: the usual ones (from oldstable to experimental), *-updates (ex volatile), *-proposed-updates, and *-backports (from Wheezy on)

Via sources.d.n you can therefore browse the content of Debian source packages with usual code viewing features like syntax highlighting. More interestingly, you can search through the source code (of unstable only, though) via integration with http://codesearch.debian.net. You can also use sources.d.n programmatically to query available versions or link to specific lines, with the possibility of adding contextual pop-up messages (example). In fact, you might have stumbled upon sources.d.n already in the past few days, via other popular Debian services where it has already been integrated. In particular: codesearch.d.n now defaults to show results via sources.d.n, and the PTS has grown new "browse source code" hyperlinks that point to it. If you've ideas of other Debian services where sources.d.n should be integrated, please let me know. I find Debsources and sources.d.n already quite useful but, as it often happens, there is still a lot TODO. Obviously, it is all Free Software (released under GNU AGPLv3). Do not hesitate to report new bugs and, better, to submit patches for the outstanding ones. Acknowledgements

• Matthieu Caneill is the main developer of Debsources web front-end; sources.d.n wouldn't exist without him.
• others have already contributed patches to integrate sources.d.n with other services, in particular:
• many thanks to Michael Stapelberg (for codesearch.d.n integration), and
• Paul Wise (for PTS integration).
• a full list of contributors is available and eagerly waiting for new additions
• IRILL has kindly provided sponsoring for Matthieu's initial development work on Debsources, and offered both the server and hosting facilities that power sources.d.n

PS in case you were wondering: at present sources.d.n requires ~381 GB of disk space to hold all uncompressed source packages, plus ~83 GB for the local (compressed) source mirror

all Debian source are belong to us TL;DR: go to http://sources.debian.net and enjoy.

---

Debsources is a new toy I've been working on at IRILL together with Matthieu Caneill. In essence, debsources is a simple web application that allows to publish an unpacked Debian source mirror on the Web. You can deploy Debsources where you please, but there is a main instance at http://sources.debian.net (sources.d.n for short) that you will probably find interesting. sources.d.n follows closely the Debian archive in two ways:

1. it is updated 4 times a day to reflect the content of the Debian archive
2. it contains sources coming from official Debian suites: the usual ones (from oldstable to experimental), *-updates (ex volatile), *-proposed-updates, and *-backports (from Wheezy on)

Via sources.d.n you can therefore browse the content of Debian source packages with usual code viewing features like syntax highlighting. More interestingly, you can search through the source code (of unstable only, though) via integration with http://codesearch.debian.net. You can also use sources.d.n programmatically to query available versions or link to specific lines, with the possibility of adding contextual pop-up messages (example). In fact, you might have stumbled upon sources.d.n already in the past few days, via other popular Debian services where it has already been integrated. In particular: codesearch.d.n now defaults to show results via sources.d.n, and the PTS has grown new "browse source code" hyperlinks that point to it. If you've ideas of other Debian services where sources.d.n should be integrated, please let me know. I find Debsources and sources.d.n already quite useful but, as it often happens, there is still a lot TODO. Obviously, it is all Free Software (released under GNU AGPLv3). Do not hesitate to report new bugs and, better, to submit patches for the outstanding ones. Acknowledgements

• Matthieu Caneill is the main developer of Debsources web front-end; sources.d.n wouldn't exist without him.
• others have already contributed patches to integrate sources.d.n with other services, in particular:
  • many thanks to Michael Stapelberg (for codesearch.d.n integration), and
  • Paul Wise (for PTS integration).
• a full list of contributors is available and eagerly waiting for new additions
• IRILL has kindly provided sponsoring for Matthieu's initial development work on Debsources, and offered both the server and hosting facilities that power sources.d.n

PS in case you were wondering: at present sources.d.n requires ~381 GB of disk space to hold all uncompressed source packages, plus ~83 GB for the local (compressed) source mirror

By now, Debian ships quite a lot of Haskell packages (~600). Because of GHC's ABI volatility, whenever we upload a new version of a library, we have to rebuild all libraries that depend on that. In particular, if we upload a new version of the compiler itself, we have to rebuild all Haskell library packages. So we have to rebuild stuff a lot. Luckily, Debian has a decent autobuilding setup so that I just need to tell it what to rebuild, and the rest happens automatically (including figuring out the actual order to build things).
I was curious how much we use the buildd system compared to other packages, and also how long the builders are busy building Haskell packages. All the data is in a postgresql database on buildd.debian.org, so with some python and javascript code, I can visualize this. The graphs show the number of all uploads by autobuilder on the amd64 architecture, with haskell uploads specially marked, and the second graph does the same for the build time. You can select time ranges and get aggregate statistics for that time span. During the last four days a complete rebuild was happening, due to the upload of GHC 7.6.3. During these 2 days and 18 hours building 537 packages took 48 hours of build time and produced 15kg of CO₂. That is 94% of all uploads and 91% the total build time. The numbers are lower for the whole of last year: 52% of uploads, 31% of build time and 57kg of CO₂. (The CO₂ numbers are very rough estimates.)
Note that amd64 is a bit special, as most packages are uploaded on this architecture by the developers, so no automatic builds are happening. On other architectures have, every upload of a (arch:any) package is built, so the share of Haskell packages will be lower. Unfortunately, at the moment the database does not provide me with a table across all architectures (and I was too lazy to make it configurable yet).

Dear Project Members,

   "Now that I have your attention, I would like to make the following
delegations:"

... nah, scrap that. In my last day in office I first of all owe you a report of DPL activities for the last reporting period of this term, i.e. March 8th until today. Here it is! Highlights

• At LibrePlanet (see below) I've discussed at length with Karen Sandler as GNOME representative the possibility of Debian participation in the FOSS Outreach Program for Women. I've then proposed that we do participate and, as you might have read on d-d-a, we're now doing that. Many thanks to the volunteer co-organizers for Debian participation in the program: M nica Ram rez Arceda, Ana Guerrero L pez, and Patty Langasek.
• A couple of years of work with the auditors has come together. At elgar.debian.org:/srv/accounting.debian.org/ledger/ you can now find Debian monetary transactions for the 2010-2013 period. Note that: 1) They are not all of our transactions, most notably because we haven't yet managed to get access to all our bank transactions at SPI (while we do have access to other transactions there, e.g. donations). Given the relevance of the missing transactions for our budget, this is a blocker for producing meaningful public periodic reports of Debian finances. This is clearly annoying, but I'm confident that our feedback to SPI over the past years has helped them better understand our needs and improve. I hope this could be finally solved during the next DPL term. And, 2) Donor names have been anonymized in the ledger files, in wait of a donation system that allow to express privacy preferences. Complete donation information is available in the companion ledger.git repository, which is accessible to auditors only. I'd like to thank the Debian auditors, and in particular Martin Michlmayr, for their amazing work on this over the past 3 years.
• As you might have noticed, we now have an official Debian Project blog, finally entering the brave new Web 1.5 era I've only helped "politically" here and there with this over the years, and I'm happy to see it live. Your thanks for this should go to the blog editors---Francesca Ciceri and Ana Guerrero Lopez---and to DSA for making it real. A proper delegation for the editors is pending and I'm confident the next DPL will pick it up.

Talks Over the past month or so I've attended and spoken on behalf of Debian in the following occasions:

• "Debian: 20 years and counting" talk at the New York Linux User Group; slides are available. Many thanks to Brian Gupta and Tom Limoncelli for inviting me.
• "Debian and GNU" talk at LibrePlanet 2013; slides are available. Many thanks to John Sullivan and the Free Software Foundation for inviting me to talk at their main conference. My presence there has also been a chance to reassess the status of collaboration with FSF (see John's brief summary) and discuss further technical collaboration with the Trisquel maintainers.
• "Legal issues from a radical community angle" keynote at the yearly workshop of FSFE's European Legal Network; slides are available. The talk has also been covered by a LWN feature article last week (the link should become unembargoed for non-LWN subscribers starting tomorrow).

Assets I've approved the budget for the following forthcoming sprints:

• 6th Debian Groupware Meeting (~500 EUR)
• DSA sprint (~3'000 EUR)

Also, we've bought a 3-year warranty pack for the disk array that powers ftp-master.d.o (~900 USD). On the income side, Brian Gupta has started an interesting matching fund experiment, in order to raise funds for the forthcoming DebConf13. The matching fund will be open until April 30th, so your help in spreading news would be welcome. Many thanks to Brian for the idea and to his company, Brandorr Group, for funding it. DPL helpers Three more DPL helpers IRC meetings have been held; minutes are available at the usual place. Legal Spring Cleaning I've finally cleaned up the pile of pending legal matters (but I'm sure new ones will show up for the delight of the next DPL :-P)

• one is merely internal for trademark@d.o: our procedures for (n)acks on incoming requests has now been vetted by our legal advisors
• the second one is relevant for our mentors.debian.net service: one of the blockers to officialize it as mentors.debian.org have historically been DMCA-related concerns. We now have a DMCA policy for (wannabe) mentors.d.o, which I've shared with the service maintainers and DSA. This specific part should no longer be a concern.
• the last one concerns the possibilities of playing DVDs with Debian. We now have legal guidelines on how to include installer packages that allow to do so; that should allow us to have a decent solution for our users in the Jessie time frame.

Once again, I'd like to thank SFLC for the pro bono and very high quality legal advice they keep on offering to Debian. Miscellaneous

• I've mentioned last month that, as a Debian representative, I've joined a working group by the Italian public administration (PA) that should define procurement rules for software in the PA at large, together with representatives of other well-known FOSS initiatives (e.g. KDE, FSFE). The first meetings have now been held and I've participate in some, for the moment on my own budget. I'll check with the next DPL the feasibility of keep on doing so on in the future.

---

Now, before I get sentimental, let me thank Gergely, Lucas, and Moray for running in the recently concluded DPL election. Only thinking of running and then go through a campaign denote a very high commitment to the Project; we should all be thankful to them. Then I'd like to congratulate Lucas for his election. I've known him for a long time, and I can testify about his clear vision of the role Debian has to play in Free Software and on what Debian needs to improve to do so. Best wishes for the term ahead, Lucas! Finally, I'd like to thank you all for the support you've shown me over the past 3 years. Serving as DPL is a great honor, but also a very demanding job. Thank to you all, and to how cool Debian is, it has been for me an incredibly rewarding experience. I had no idea what I were doing when I embarked on this adventure, but in hindsight I don't regret any of it. See you around, as I don't plan to be anywhere far away from Debian anytime soon. Cheers.

---

PS the day-to-day activity logs for March and April 2013 are available at the usual place master:/srv/leader/news/bits-from-the-DPL.txt.20130 3,4

As some may have seen, zack put out a note about the GNOME OPW. The GNOME OPW program, as some of you may know, is the GNOME Outreach Program for Women. Debian has been considering participating this year, and I think it s something we should focus on this year. So, please, if you have ideas, please feel free to send along ideas on that thread it d be amazing to get this going (in conjunction with) GSoC this year. Also, if you have any GSoC ideas, please do also add those! GNOME OPW allows for things that are non-technical, so feel free to post non-technical things too (publicity team, www team, I m looking at you!)

Ladies and gentlemen, I'm so excited to present you the official blog of the Debian Project. The idea is to make it the voice of the project, in addition to the official press releases and DPN, our bi-weekly newsletter.
I'm really excited about it not only because it will help us to communicate better with our users in letting them know what is going on, but also because it's something we long waited (and planned) for. And it was surely a collective effort: many thanks to Ana Guerrero, who not only is one of the main editors, but also the engine behind the idea and the realization of it; Stefano Zacchiroli, who during his three terms as DPL gave lots of support to this idea; and the Debian System Administrators Team who put all in place (and found the perfect name for it).

Dear project members, here's another report of DPL activities, this time for a period longer than usual (February + 1st week of March), so that the next one will be at the very end of the current DPL term. Highlights

• As you know, we are now well within the DPL election process. And we have 3 valuable candidates running. I encourage all of you to participate in the discussions on -vote, and ask questions about project vision, goals, and improvements. It's something that is rarely as intense as during campaigning, so don't miss the chance!
• You might have noticed a sharp decrease in the count of RC bugs affecting Wheezy; that is largely due to the Release Team, who started the usual final sweep of RC triaging before release. Please thank them for their work, ... but don't give up on our collective work yet! You can still help up in the usual ways (NMUs, severity adjustments, unblock reviews, etc).
• The technical committee had to deal with a rather urgent issue during last month (#699808). I mention it here only to applaud their efficiency in doing so: 4 days to reach a decision. Resorting to tech-ctte shall always remain a last resort in Debian, but when it comes to that it's useful to know that we can count on a wise and speedy answer.

Appointments

• As the previous term was about to end, I've agreed with the Kurt Roeckx to re-appoint him as Project Secretary for another year.
• Following up to last month news, we've now assembled a team of admins for Debian participation into Google Summer of Code 2013 and delegated them for the task. Many thanks to David, Nicolas, Paul, and Sukhbir for volunteering, as well as to last year admins for their help in reaching out to interested volunteers. On a related note, we've until March 28th to propose projects and/or volunteer as (co-)mentor for GSoC 2013.

DPL helpers Two more DPL helpers IRC meetings have happened, minutes and logs of both are available. Assets

• I've worked with the press and publicity teams to announce the new trademark policy more widely and call for producing Wheezy merchandise. Apparently, we are now also being cited as a reference on how to strike a balance between free software and trademark (unfortunately the article is behind a paywall now).
• In related news, Brian Gupta has volunteered to help with answering trademark@d.o inquiries and has already helped a lot in streamlining the process and keeping track of past requests (thanks!)
• Following a -project inquiry by Thomas Koch, I've investigated with SPI the possibility of assigning to them the copyright for (code) contributions to Debian. The bottom line is that at present there is no safe way to do that with SPI; that might change in the future.
• As agreed at a DPL helpers meeting, we are trying to federate interests in Debian sponsoring and fund-raising. Part of the goal is avoid duplication of efforts DebConf- and sponsoring for other Debian activities; and part is establishing a more stable income flow for Debian (to ease long-term budget decisions). If you have experience and interest in this area, please join the debian-sponsors-discuss list on Alioth.
• Together with auditors, we have updated reimbursement procedures to better keep track of both outstanding and past requests. Main difference is that you'll now have to mail a RT queue instead of leader@d.o directly. Check the wiki page for details.

Events Past At the beginning of February, I've attended FOSDEM 2013, together with many other Debian people. I didn't have any specific talk this year, but it's been a chance to talk F2F about several ongoing issues (see logs), and help mediating in some conflicts. I've also accepted the invitation to participate in the GNOME Advisory Board meeting, together with Laurent Bigonville of our GNOME team. No report of that has been prepared as of yet (sorry about that), but we have both reported "live" to the rest of the team on IRC. Future

• It looks like my last month as DPL will be quite busy. Next week I'll be first in New York City, delivering an invited Debian talk at NYLUG (thanks a lot to Brian Gupta and Tom Limoncelli for the invitation). Then I'll head to LibrePlanet 2013 to talk about the relationship between Debian and GNU (thanks to John Sullivan for the invitation). Finally, at the beginning of April, I'll be in Amsterdam to deliver a talk about Debian experience with various legal issues across the years, at the yearly FSFE Legal and Licensing Workshop (thanks to Karsten Gerloff for the invitation). Both trips (LibrePlanet and FSFE) will be on Debian budget. While I usually insist on having travel sponsorship from inviting entities, in this cases I've accepted to do otherwise given they are free software non profits like Debian.
• I've been invited to represent Debian at Distro Recipes. Due to a conflict with FSFE workshop I couldn't make, so I've looked for substitutes. Lucas Nussbaum and Jonas Smedegaard have kindly accepted to go in my stead and deliver two talks, one about QA and the other about Pure Blends; thanks folks!

Miscellaneous A couple of months ago I've mentioned that I had filed an application, as Debian representative, to participate in a working table to define software procurement rules for the Italian public administration. Good news: my application has been accepted, together with those of other well-known FOSS communities and organizations (e.g. KDE, FSFE). I'll keep you posted of how it goes. Let's go back to elect a new DPL and release Wheezy now,
Cheers.

---

PS the day-to-day activity logs for February and March 2013 are available at the usual place master:/srv/leader/news/bits-from-the-DPL.txt.20130 2,3